<div class="container">
     <h1 id="pkg-overview">package build</h1>

        <p><code>import "go/build"</code>

        </p><p>
Package build gathers information about Go packages.
</p>
<h3 id="hdr-Go_Path">Go Path </h3>
<p>
The Go path is a list of directory trees containing Go source code.
It is consulted to resolve imports that cannot be found in the standard
Go tree. The default path is the value of the GOPATH environment
variable, interpreted as a path list appropriate to the operating system
(on Unix, the variable is a colon-separated string;
on Windows, a semicolon-separated string;
on Plan 9, a list).
</p>
<p>
Each directory listed in the Go path must have a prescribed structure:
</p>
<p>
The src/ directory holds source code. The path below 'src' determines
the import path or executable name.
</p>
<p>
The pkg/ directory holds installed package objects.
As in the Go tree, each target operating system and
architecture pair has its own subdirectory of pkg
(pkg/GOOS_GOARCH).
</p>
<p>
If DIR is a directory listed in the Go path, a package with
source in DIR/src/foo/bar can be imported as "foo/bar" and
has its compiled form installed to "DIR/pkg/GOOS_GOARCH/foo/bar.a"
(or, for gccgo, "DIR/pkg/gccgo/foo/libbar.a").
</p>
<p>
The bin/ directory holds compiled commands.
Each command is named for its source directory, but only
using the final element, not the entire path. That is, the
command with source in DIR/src/foo/quux is installed into
DIR/bin/quux, not DIR/bin/foo/quux. The foo/ is stripped
so that you can add DIR/bin to your PATH to get at the
installed commands.
</p>
<p>
Here's an example directory layout:
</p>
<pre>GOPATH=/home/user/gocode

/home/user/gocode/
    src/
        foo/
            bar/               (go code in package bar)
                x.go
            quux/              (go code in package main)
                y.go
    bin/
        quux                   (installed command)
    pkg/
        linux_amd64/
            foo/
                bar.a          (installed package object)
</pre>
<h3 id="hdr-Build_Constraints">Build Constraints </h3>
<p>
A build constraint, also known as a build tag, is a line comment that begins
</p>
<pre>// +build
</pre>
<p>
that lists the conditions under which a file should be included in the package.
Constraints may appear in any kind of source file (not just Go), but
they must appear near the top of the file, preceded
only by blank lines and other line comments. These rules mean that in Go
files a build constraint must appear before the package clause.
</p>
<p>
To distinguish build constraints from package documentation, a series of
build constraints must be followed by a blank line.
</p>
<p>
A build constraint is evaluated as the OR of space-separated options;
each option evaluates as the AND of its comma-separated terms;
and each term is an alphanumeric word or, preceded by !, its negation.
That is, the build constraint:
</p>
<pre>// +build linux,386 darwin,!cgo
</pre>
<p>
corresponds to the boolean formula:
</p>
<pre>(linux AND 386) OR (darwin AND (NOT cgo))
</pre>
<p>
A file may have multiple build constraints. The overall constraint is the AND
of the individual constraints. That is, the build constraints:
</p>
<pre>// +build linux darwin
// +build 386
</pre>
<p>
corresponds to the boolean formula:
</p>
<pre>(linux OR darwin) AND 386
</pre>
<p>
During a particular build, the following words are satisfied:
</p>
<pre>- the target operating system, as spelled by runtime.GOOS
- the target architecture, as spelled by runtime.GOARCH
- the compiler being used, either "gc" or "gccgo"
- "cgo", if ctxt.CgoEnabled is true
- "go1.1", from Go version 1.1 onward
- "go1.2", from Go version 1.2 onward
- "go1.3", from Go version 1.3 onward
- "go1.4", from Go version 1.4 onward
- "go1.5", from Go version 1.5 onward
- "go1.6", from Go version 1.6 onward
- "go1.7", from Go version 1.7 onward
- "go1.8", from Go version 1.8 onward
- any additional words listed in ctxt.BuildTags
</pre>
<p>
If a file's name, after stripping the extension and a possible _test suffix,
matches any of the following patterns:
</p>
<pre>*_GOOS
*_GOARCH
*_GOOS_GOARCH
</pre>
<p>
(example: source_windows_amd64.go) where GOOS and GOARCH represent
any known operating system and architecture values respectively, then
the file is considered to have an implicit build constraint requiring
those terms (in addition to any explicit constraints in the file).
</p>
<p>
To keep a file from being considered for the build:
</p>
<pre>// +build ignore
</pre>
<p>
(any other unsatisfied word will work as well, but “ignore” is conventional.)
</p>
<p>
To build a file only when using cgo, and only on Linux and OS X:
</p>
<pre>// +build linux,cgo darwin,cgo
</pre>
<p>
Such a file is usually paired with another file implementing the
default functionality for other systems, which in this case would
carry the constraint:
</p>
<pre>// +build !linux,!darwin !cgo
</pre>
<p>
Naming a file dns_windows.go will cause it to be included only when
building the package for Windows; similarly, math_386.s will be included
only when building the package for 32-bit x86.
</p>
<p>
Using GOOS=android matches build tags and files as for GOOS=linux
in addition to android tags and files.
</p>
<h3 id="hdr-Binary_Only_Packages">Binary-Only Packages </h3>
<p>
It is possible to distribute packages in binary form without including the
source code used for compiling the package. To do this, the package must
be distributed with a source file not excluded by build constraints and
containing a "//go:binary-only-package" comment.
Like a build constraint, this comment must appear near the top of the file,
preceded only by blank lines and other line comments and with a blank line
following the comment, to separate it from the package documentation.
Unlike build constraints, this comment is only recognized in non-test
Go source files.
</p>
<p>
The minimal source code for a binary-only package is therefore:
</p>
<pre>//go:binary-only-package

package mypkg
</pre>
<p>
The source code may include additional Go code. That code is never compiled
but will be processed by tools like godoc and might be useful as end-user
documentation.</p>


        
  


        
        

        

        

        
        
          
        

        
        


<p><a href="https://github.com/golang/go/blob/master/src/go/build/build.go">build.go</a> <a href="https://github.com/golang/go/blob/master/src/go/build/doc.go">doc.go</a> <a href="https://github.com/golang/go/blob/master/src/go/build/read.go">read.go</a> <a href="https://github.com/golang/go/blob/master/src/go/build/syslist.go">syslist.go</a> </p>

        
        

        
        
          <h2 id="pkg-variables">Variables </h2>
          <p>
ToolDir is the directory containing build tools.
</p>

        

        
        
        
          <h2 data-kind="f" id="ArchChar">func <a href="https://github.com/golang/go/blob/master/src/go/build/build.go#L1563" title="View Source">ArchChar</a>  </h2>
          <p>
ArchChar returns "?" and an error.
In earlier versions of Go, the returned string was used to derive
the compiler and linker tool names, the default object file suffix,
and the default linker output name. As of Go 1.5, those strings
no longer vary by architecture; they are compile, link, .o, and a.out, respectively.
</p>

          
  

        
          <h2 data-kind="f" id="IsLocalImport">func <a href="https://github.com/golang/go/blob/master/src/go/build/build.go#L1553" title="View Source">IsLocalImport</a>  </h2>
          <p>
IsLocalImport reports whether the import path is
a local import path, like ".", "..", "./foo", or "../foo".
</p>

          
  

        

        
        

        
          <h2 data-kind="t" id="Context">type <a href="https://github.com/golang/go/blob/master/src/go/build/build.go#L30" title="View Source">Context</a>  </h2>
          <p>
A Context specifies the supporting context for a build.
</p>

          
          <p>
Default is the default Context for builds.
It uses the GOARCH, GOOS, GOROOT, and GOPATH environment variables
if set, or else the compiled code's GOARCH, GOOS, and GOROOT.
</p>

          
  


          

          
            <h3 data-kind="m" id="Context.Import">func (*Context) <a href="https://github.com/golang/go/blob/master/src/go/build/build.go#L486" title="View Source">Import</a>  </h3>
            <p>
Import returns details about the Go package named by the import path,
interpreting local import paths relative to the srcDir directory.
If the path is a local import path naming a package that can be imported
using a standard import path, the returned package will set p.ImportPath
to that path.
</p>
<p>
In the directory containing the package, .go, .c, .h, and .s files are
considered part of the package except for:
</p>
<pre>- .go files in package documentation
- files starting with _ or . (likely editor temporary files)
- files with build constraints not satisfied by the context
</pre>
<p>
If an error occurs, Import returns a non-nil error and a non-nil
*Package containing partial information.
</p>

            
  

          
            <h3 data-kind="m" id="Context.ImportDir">func (*Context) <a href="https://github.com/golang/go/blob/master/src/go/build/build.go#L434" title="View Source">ImportDir</a>  </h3>
            <p>
ImportDir is like Import but processes the Go package found in
the named directory.
</p>

            
  

          
            <h3 data-kind="m" id="Context.MatchFile">func (*Context) <a href="https://github.com/golang/go/blob/master/src/go/build/build.go#L1032" title="View Source">MatchFile</a>  </h3>
            <p>
MatchFile reports whether the file with the given name in the given directory
matches the context and would be included in a Package created by ImportDir
of that directory.
</p>
<p>
MatchFile considers the name of the file and may use ctxt.OpenFile to
read some or all of the file's content.
</p>

            
  

          
            <h3 data-kind="m" id="Context.SrcDirs">func (*Context) <a href="https://github.com/golang/go/blob/master/src/go/build/build.go#L238" title="View Source">SrcDirs</a>  </h3>
            <p>
SrcDirs returns a list of package source root directories.
It draws from the current Go root and Go path but omits directories
that do not exist.
</p>

            
  

          
        
          <h2 data-kind="t" id="ImportMode">type <a href="https://github.com/golang/go/blob/master/src/go/build/build.go#L325" title="View Source">ImportMode</a>  </h2>
          <p>
An ImportMode controls the behavior of the Import method.
</p>

          
          
          
  


          

          
        
          <h2 data-kind="t" id="MultiplePackageError">type <a href="https://github.com/golang/go/blob/master/src/go/build/build.go#L451" title="View Source">MultiplePackageError</a>  </h2>
          <p>
MultiplePackageError describes a directory containing
multiple buildable Go source files for multiple packages.
</p>

          
          
          
  


          

          
            <h3 data-kind="m" id="MultiplePackageError.Error">func (*MultiplePackageError) <a href="https://github.com/golang/go/blob/master/src/go/build/build.go#L457" title="View Source">Error</a>  </h3>
            
            
  

          
        
          <h2 data-kind="t" id="NoGoError">type <a href="https://github.com/golang/go/blob/master/src/go/build/build.go#L441" title="View Source">NoGoError</a>  </h2>
          <p>
NoGoError is the error used by Import to describe a directory
containing no buildable Go source files. (It may still contain
test files, files hidden by build tags, and so on.)
</p>

          
          
          
  


          

          
            <h3 data-kind="m" id="NoGoError.Error">func (*NoGoError) <a href="https://github.com/golang/go/blob/master/src/go/build/build.go#L445" title="View Source">Error</a>  </h3>
            
            
  

          
        
          <h2 data-kind="t" id="Package">type <a href="https://github.com/golang/go/blob/master/src/go/build/build.go#L372" title="View Source">Package</a>  </h2>
          <p>
A Package describes the Go package found in a directory.
</p>

          
          
          
  


          
            <h3 data-kind="f" id="Import">func <a href="https://github.com/golang/go/blob/master/src/go/build/build.go#L1117" title="View Source">Import</a>  </h3>
            <p>
Import is shorthand for Default.Import.
</p>

            
  

          
            <h3 data-kind="f" id="ImportDir">func <a href="https://github.com/golang/go/blob/master/src/go/build/build.go#L1122" title="View Source">ImportDir</a>  </h3>
            <p>
ImportDir is shorthand for Default.ImportDir.
</p>

            
  

          

          
            <h3 data-kind="m" id="Package.IsCommand">func (*Package) <a href="https://github.com/golang/go/blob/master/src/go/build/build.go#L428" title="View Source">IsCommand</a>  </h3>
            <p>
IsCommand reports whether the package is considered a
command to be installed (not just a library).
Packages named "main" are treated as commands.
</p>

<div class="clearfix" id="x-footer">
  <div class="container">
    <a href="http://studygolang.com/" target="_blank">Go语言中文网</a>
    <span class="text-muted">|</span> <a href="http://golang.org/" target="_blank">Go Language</a>
    <span class="pull-right"><a href="#">Back to top</a></span>
  </div>
</div>
<script src="../assets/jquery-2.0.3.min.js"></script>
<script src="../assets/bootstrap.min.js"></script>
<script src="../assets/site.js"></script>


</div>